Einem guten Rat folgend überlege ich welches Spiel ich nachprogrammiere. Man muss sich ja Ziele setzen, aber auch welche die man erreichen kann. Das ist für mich in diesem frühen Stadium nur schwer abzuschätzen, aber ich denke sowas wie Galaga/Galaxian wäre vielleicht für den Anfang besser als ein aufwändiger Scroller/Shooter? So richtig reizen würde mich ja sowas wie Giana Sisters, das kenne ich vom C64, oder das ein oder andere Space-Shooter-Game vom CPC464. Aber vielleicht sollte ich lieber erstmal mit Pong anfangen?
Mein erstes Spiel...
Also 1. finde ich es echt super, wie du das angehst... kommt mir bekannt vor!! Ich habe ja auch mit einem Shooter angefangen und das war eine super Idee, weil man da so viel lernt... Shooter ist auf jeden Fall schwieriger, als Nicht-Shooter 😉
Galaxien/Galaga ... puh ... das würde ich mir vielleicht jetzt nach fast drei Jahren zutrauen. Ist natürlich machbar und du bekommst hier auf jeden Fall Hilfe auf alle Fragen!! Hau rein!!!!
M.U.L.E. 😉
. Hallo WiesoMehrTeeAcht
An Giana Sisters für den Atari 8 Bit wird schon seit einiger Zeit gearbeitet.
Tschüß
Mathy
Schreibe nicht der Absicht zu, was man mit Dummheit oder Ignoranz erklären kann.
Ok, dann versuche ich mich mal an "Galaxian" 🙂
Mal analysieren was wir da haben: 1.) Starfield-Simulation im Hintergrund 2.) Das eigene Schiff (Player 1) 3.) Die gegnerischen Schiffe in der Formation ("Kanonenfutter") 4.) Die gegnerischen Schiffe als Jäger (Kamikaze und Gegenfeuer) 5.) Titel/Hintergrundmelodie 6.) Explosions-Animation, eigenes Schiff 7.) Explosions-Animation, gegnerisches Schiff 8.) Sound-Effekt, eigener Schuss 9.) Sound-Effekt, gegnerischer Schuss 10.) Sound-Effekt, Explosion Gegner 11.) Sound-Effekt, Explosion eigenes Schiff 12.) Level, Leben und High-Score Anzeige 13.) Schuss-Animation vom eigenen Schiff 14.) Schuss-Animationen der gegnerischen Schiffe
Vom DLIST-Aufbau her sieht das sehr nach erster Zeile im Text-Modus und der Rest im Graphik-Modus aus.
Das eigene Schiff wäre wohl ein Sprite, aber wie macht man die Gegner sodass man diese pixelweise in der Formation und nahezu frei im Angriff bewegen kann? Nimmt man dafür Tiles, einen Character-Font oder Software-Sprites? Man braucht ja auch ne Kollisionserkennung usw.
Das Starfield wäre doch ein vertical-scroll bei dem oben in der obersten Zeile per Random ein paar Pixel in verschiedenen Helligkeitsstufen eingestellt und dann nach unten gescrollt würden? Mir fällt auf das die "Sterne" dabei immer mal flackern. Ob das gewollt war oder ein Nebeneffekt? Ich rätsele wie man so einen Effekt im Hintergrund des Spielfeldes hin bekommen könnte, ohne dabei die Grafik zu beeinflussen?
könnte Antic 4 oder 5 sein... Wahrscheinlich brauchst du Softwaresprites für die Gegner Dein Player ist mehrfarbig... brauchst also mehrere Player zusammen Kollisionserkennung habe ich bei Caverns of Eris mittels Hitboxen gemacht
Ich hätte ja gerne mal sowas wie Hypa-Ball auf dem Atari: https://www.c64-wiki.de/wiki/Hypa-Ball
🙂
/|\ ... loading .... /|\
yMoreT8 schrieb: Ok, dann versuche ich mich mal an "Galaxian" 🙂 Vom DLIST-Aufbau her sieht das sehr nach erster Zeile im Text-Modus und der Rest im Graphik-Modus aus.
Man kann sich in Altirra 2.6 die Display-List eines laufenden Spiels ansehen: Einfach per F8 in Debugger gehen, in den Atari-Bildschirm klicken und dann bei gedrückter Shift-Taste Mauszeiger über eine Bildschirmzeile halten. (Seltsamerweise geht das nicht in neueren Altirra-Versionen ?!?)
Bei Galaxian wird für die oben wartenden Gegner ANTIC-Modus E verwendet (2x1 Rasterpunkte große Pixel in 3 Farben) und ansonsten gibt es fast nur Leerzeilen (ANTIC $70). Die Sterne und herabstürzenden Gegner sind also offenbar Missiles und Player. Interessant!
skr schrieb: Ich hätte ja gerne mal sowas wie Hypa-Ball auf dem Atari: https://www.c64-wiki.de/wiki/Hypa-Ball
🙂
Ich bin mir sicher sowas schon damals am ATARI gespielt zu haben... War das "Hydra Ball"?
Ah, gefunden: https://a8.fandal.cz/detail.php?files_id=5520
PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo
JoSch schrieb: M.U.L.E. 😉
Ich glaube das gibt es schon... Wobei ich es noch nie gespielt habe.
pps schrieb:
skr schrieb: Ich hätte ja gerne mal sowas wie Hypa-Ball auf dem Atari: https://www.c64-wiki.de/wiki/Hypa-Ball
🙂
Ich bin mir sicher sowas schon damals am ATARI gespielt zu haben... War das "Hydra Ball"?
Ah, gefunden: https://a8.fandal.cz/detail.php?files_id=5520
Dies war mal ein Beitrag für die "Diskline" von PPP/W.Rätz, also kein wirklich kommerz. Spiel. Inzwischen sind die Disklines ja PD... Antist war u.a. S.Sölbrandt, bekannt von den Games "Die Zeitmaschine", "Die Zeitmaschine 2 - Die Rückkehr", "Die Zeitmaschine 3 - Die Außerirdischen", aber auch "Bright Eyes", "Crillion" und anderen Games.
CharlieChaplin schrieb:
JoSch schrieb: M.U.L.E. 😉
Ich glaube das gibt es schon... Wobei ich es noch nie gespielt habe.
Waaaaaas? Noch nie M.U.L.E gespielt? Das geht ja mal garnicht!
PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo
pps schrieb:
skr schrieb: Ich hätte ja gerne mal sowas wie Hypa-Ball auf dem Atari: https://www.c64-wiki.de/wiki/Hypa-Ball
🙂
Ich bin mir sicher sowas schon damals am ATARI gespielt zu haben... War das "Hydra Ball"?
Ah, gefunden: https://a8.fandal.cz/detail.php?files_id=5520
Entweder es ist mir entfallen, oder ich habe es absichtlich vergessen, weil es sich zwar an Hypa-Ball orientiert, aber mehr auch nicht (gaaanz vorsichtig ausgedrückt 😉 ).
Dann sage ich mal (etwas unvorsichtiger) : Ich hätte gerne eine gute A8-Version davon.
/|\ ... loading .... /|\
Ähm, seid mir nicht böse, aber gehört das hier hin in meinen Thread? Macht doch bitte einen eigenen auf, sonst wird dieser hier völlig unleserlich. Dankeschön 😉
Dietrich schrieb: Bei Galaxian wird für die oben wartenden Gegner ANTIC-Modus E verwendet (2x1 Rasterpunkte große Pixel in 3 Farben) und ansonsten gibt es fast nur Leerzeilen (ANTIC $70). Die Sterne und herabstürzenden Gegner sind also offenbar Missiles und Player.
Interessante Idee das reverse zu engineeren. Dabei kann man sicher auch so einiges lernen. Die Arcade-Version des Spieles bot etwas mehr Action, vor allem mehr als das schnöde Einzelfeuer.
Wie können die Sterne auch Missles sein? Davon hat man doch nur vier oder so? Auch meine ich das während des Spiels deutlich mehr Gegner herab kommen als Missles/Player verfügbar sind? Oder kann man Missles/Player mehrfach darstellen lassen?
Ich würde mir als allererstes überlegen mit welcher Auflösung und Art des Bildschirmes und mit welcher Speichergröße ich arbeiten will. Alles hat da so seine Vor- und Nachteile beim A8. Ich habe mir da also inzwischen eine Vorlage gemacht: 128 kB Antic4 - also arbeiten mit allen Banks. Da ist man echt am flexibelsten. Falls man noch mehr Speicher braucht, kann da noch das ROM ausschalten und das RAM unter dem ROM nutzen, das bringt nachmals ca. 3kB. Dann braucht man aber ein eigenes abgespecktes OS.
Wie anfangen?? Ich würde wohl zunächst die 128bK Vorlage Antic 4 nehmen und dann als allererstes den Sternenhintergrund bauen. Dafür würde ich wohl zunächst die Technik der Softwaresprites erlernen, das wirst du bestimmt brauchen. Natürlich führen viele Wege nach Rom, du musst halt deinen eigenen wählen. Galaxian als Startprojekt ist echt eine Herausforderung, wenn du das aber umgesetzt bekommst, kannst beherrscht du den Rechner überwiegend!
yMoreT8 schrieb: Wie können die Sterne auch Missles sein? Davon hat man doch nur vier oder so? Auch meine ich das während des Spiels deutlich mehr Gegner herab kommen als Missles/Player verfügbar sind? Oder kann man Missles/Player mehrfach darstellen lassen?
Die Player und Missiles sind keine quadratischen Sprites, wie auf anderen Systemen, sondern gehen über die volle Bildschirmhöhe. Mittels Display List Interrupts kannst du sie prinzipiell in jeder Bildschirmzweile an eine andere horizontale Position setzen und ihre Farbe ändern. Player sind 8 Bit breit, Missiles 2 Bit. Ich schreibe bewusst Bit weil man sie zwei- oder vierfach breit anzeigen lassen kann.
Oben hat Dietrich geschrieben, dass es zwischen den Aliens und dem Schiff des Spielers nur leere Zeilen gibt. Somit müssen die Sterne und angreifenden Gegner Players und Missiles sein. ANTIC zeigt sonst nichts an.
Ich rate jetzt mal - und habe kurz auf den Screenshot oben geschaut - dass es je Bildschirmzeile immer maximal einen Stern gibt. Somit ist das höchstwahrscheinlich ein einzelnes Missile für alle Sterne.
Die angreigenden Gegner sind zweifarbig und nicht immer schön eine Zeile eine Farbe, die nächste eine andere. Somit müssen sie aus mindestens zwei Objekten bestehen. Eins ist auf alle Fälle ein Player. Die zweite Farbe ist meistens nur in einzelnen Pixeln enthalten. Hier könnte also eine Missile verwendet worden sein. Zu klären ist nun noch, wieviele Angreifer horizontal nebeneinander auftauchen (können). Ich tippe mal auf zwei oder vier - je nachdem, ob die zweite Farbe ein Missile oder ein Player ist. Bei den Formationen sind es jeweils zwei nebeneinander und einer drüber, wozu dann, siehe oben, einfach einer der Player wiederverwendet wird.
Zu guter Letzt bleibt das Raumschiff des Spielers. Da wir inzwischen alle Players und Missiles verbraucht haben, ist das vermutlich ein Zeichensatzobjekt, das fein horizontal gescrollt wird. Bei Galaxian ist das ja kein Problem weil der Spieler keinerlei vertikale Bewegungsmöglichkeit hat.
wirklich gut analysiert… somit könnte der Sternenhimmel recht einfach gemacht werden! Ein Missile … der Inhalt rotiert nach unten, die xPositionen werden dann entsprechend in den einzelnen Bildschirmzeilen via DLI verändert
Ich versuche mich gerade in die PM (Player/Missile) einzuarbeiten. Die Wirkungsweise scheint logisch, die PM sind quasi die HW-Sprites des A8. Mir ist es auch nach Durcharbeiten div. Tutorials und Videos gelungen einen super einfachen Player zu programmieren und diesen auf dem Bildschirm hin und her wandern zu lassen. Man hat also 4 Player und 4 Missiles, die unabhängig voneinander gesteuert werden können. Auch deren Z-Ebene ist steuerbar (Priority) und es gibt eine Kollisionserkennung.
Man legt also irgendwo im Speicher fest wo man den Shared-Memory (shared wg. DMA Zugriff vom ANTIC/GTIA) hat der die Grafik enthält. Ein Player ist 256 Bytes groß und belegt damit 8-Bit pro Scanline, welche somit maximal 256 Zeilen umfassen kann, also mehr als darstellbar ist. Die Position in diesem Bytestream legt dann die Y-Position des Sprites fest, sowie seine Größe nach oben/unten. Breiter als 8-Bit (max. 8 Pixel) können die Sprites also nicht sein, außer man nutzt zwei Player aneinander, oder legt die Ausdehnung der Player auf das Doppelte/Vierfache fest. Wie das dann alles mit Farben funktioniert weiß ich auch noch nicht. Das alles ist auch erstmal komplett unabhängig vom gewählten ANTIC-Modus, da die Sprites wohl vom GTIA erzeugt werden?
So habe ich also einfach mal ein PMBASE eingestellt (übrigens ein Write-Only Register des ANTIC, d.H. man kann den geschriebenen Wert nicht mehr auslesen und muss ihn sich selbst irgendwo merken. Ich habe eine globale Variable namens "pb" im Programm dafür definiert. Keine Ahnung ob man das so macht oder nicht...). Die PMBASE ist ein 8-Bit Register, nimmt also nur das HI-Byte der Speicheradresse auf, somit also eine Page. Das wiederum erklärt warum die PMBASE nur auf Page-Boundary eingestellt werden kann:
; set PM base
lda #$40
sta PMBASE ; set page of PMBASE to $40 (equals memory address $4000)
sta pb ; store page of PMBASE on global variable
pb .byte $00
Laut Profibuch kann dieser Speicherbereich 1kb oder 2kb groß sein, je nachdem ob man feine (einfache) Vertikale Auflösung oder die doppelte wählt. Das ergibt sich dann wohl aus dieser Einstellung:
; set single line graphics for PM
lda #%00111110
sta SDMCTL
Somit sollte der Speicherbereich PMBASE bis PMBASE + $800 reserviert werden. Der 6502 hat keine Funktionen zum schützen von Speicher (was auch wohl der Grund ist das dort selbstmodifizierender Code funktioniert, mit moderneren CPUs ginge das so nicht.), also muss man selbst dafür sorgen das niemand anderes den PM-Speicher benutzt. Auch ist das erstmal nur eine Reservierung und man muss selbst dafür sorgen das der Speicherbereich initialisiert wird, sonst steht da womöglich irgendwelcher Datenmüll drin, der dann als Grafik interpretiert wird.
Dies habe ich mit einer Memory-Clear Funktion erreicht, welcher die gesamte PM erstmal auf $00 initialisiert. Auch das könnte/würde man sicher anders machen und gleich die Grafiken reinschreiben die man als Player/Missiles haben will?
Dann stelle ich die Priorität für player0, seine Farbe, Breite und X-Position ein:
; set same priority for all players
lda #$01
sta GPRIOR
; set color for player 0
lda #$e4 ; = color * 16 + brightness
sta PCOLR0
; set initial Xpos of player 0
lda #120
sta HPOSP0
; set width of player 0
lda #$00 ; 0=normal, 1=double, 3=quadruple
sta SIZEP0
und zu guter Letzt aktiviere ich das ganze System:
; enable PM
lda #$03
sta GRACTL
Das bringt mir dann den player0 auf den Bildschirm und ich kann ihn durch Ändern von HPOSP0 (X-Position) horizontal auf dem Bildschirm verschieben.
Hierzu aber dann gleich einige Fragen und Bitten: 1.) Das verschieben sollte sicher irgendwie mit dem HSYNC/VSYNC synchronisiert werden, oder? Also in einem der dafür bereitgestellten Interrupts. 2.) Welche Maßeinheit hat das HPOSP0? Es ist ja ein Byte, kann also 0-255 haben, aber was bedeutet das für seine Position? 3.) Wie steuere ich die Y-Position des Sprites? Muss ich da die 256 Bytes im jeweiligen Speicherblock des Players rollieren? 4.) Wie kann ich, ganz einfach den Joystick (Tastatur-Emulation im Altirra) abfragen um die X/Y Postion damit zu steuern?
Hallöle!
zu 1): Du kannst das am besten wohl im VBI machen, dann ist das optimal und ohne ruckeln syncronisiert. Alternativ im Hauptprogramm, dann mit kleiner Wartescheife, die über den Taktzähler gesteuert wird zu 2): schau mal hier, dazu habe ich einen Post eingestellt. https://abbuc.de/forum/viewtopic.php?f=7&t=715 zu 3): du musst tatsächlich die Bits entsprechend schreiben und löschen. Mein Player ist animiert und im VBI wird ständig mit einem Zähler Daten in den entsprechenden Player eingeschrieben. Die Daten habe ich in einer Tabelle abgelegt. Der Zähler steuert die Geschwindigkeit der Animation und die Reihenfolge. Mein Player hat als erstes und als letztes eine Leerzeile, so stellt man sicher, daß bei der Bewegung immer der obere oder untere Teil gelöscht wird. Kann man anders machen, schien mir aber so am einfachsten. Ich mache sogar 2 Leerzeilen über und unter den Playerdaten frei, das reduziert Fehler. Für die Bewegung des jeweiligen Players definiere ich zwei Variablen für die x- / und y-Position. Mit diesen Variablen rechne ich . zu 4): Im Profibuch Seite 183 gibt es eine super Routine für die Joystickabfrage. Die packe ich auch immer in den VBI.
hier die Warteschleife, die CPU-Takt gesteuert ist:
.proc warte0
lda RTCLOK+2
@
cmp RTCLOK+2
beq @-
rts
.endp
4.) Einfache Joystickabfrage. Der ATARI beschreibt im VBI immer das Joystickregister. Also sollte diese Routine einfach regelmäßig aufgerufen werden.
.proc joytest ;ändert x und y Register
ldy STICK0 ;632 -> Schattenregister Joyport 0
ldx t_joy,y ;im x Register haben wir entweder 0, oder eine Zahl, je nach Richtung
rts
t_joy
/*
1-links
2-rechts
3-hoch
4-runter
*/
dta b(0,0,0,0,0,0,0,2,0,0,0,1,0,4,3,0)
.endp
Nur nach Rechts und Links abfragen, kann man dann auch mit 1 und 255 für Links und Rechts machen. Dann ist einfaches Verzweigen möglich:
jsr joytest
bmi rechts
bpl links
3.) y (also die Höhe des Sprites) muss, wie vermutet durch Kopieren innerhalb der 256 (bzw. 128) Bytes des Players/Missiles erfolgen. 2.) hposp0..3 ist die linke Position des 8 Sprite Pixel. Der "normale" Bildschirm beginnt hier bei Position 32 ($20). 1.) Wann Du das Sprite verschiebst, ist Dir überlassen. Man kann dies im VBI oder DLI rehct einfach machen, aber es geht auch direkt im Code außerhalb der Interrupts.
Bei zweizeiliger Auflösung nutzt die PM-Grafik nur je Player und für die Missiles 128 Bytes. Der Beginn nach PMBASE ist dann entsprechend anders.
PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo
... aus Tradition, wegen Übersichtlichkeit und Bequemlichkeit nutze ich nicht selten die mögliche If Then Anweisung bei MADS. Die einfache If Then Anweisung ist dabei hinsichtlich Schnelligkeit und Codelänge der normalen Codierung gleichwertig, komplexere Dinge kann man auch gut machen, ist aber länger und langsam - das habe ich getestet!
Hier mal ein Beispiel, wie das aufgebaut ist:
#if .byte variable=#1
.... code ...
#end
#if .byte variable1=variable2 .and .byte variable3=#12
... code ...
... rts / jmp ... ; man kann hier auch direkt rausspringen
#end
Hier meine Joystickroutine:
.proc joystick
#if .byte stick0=#7 ;nach rechts
jsr rechts
jmp @+
#end
#if .byte stick0=#6 ;nach rechts oben
jsr rechts
jsr oben
jmp @+
#end
#if .byte stick0=#10 ;nach links oben
jsr links
jsr oben
jmp @+
#end
#if .byte stick0=#11 ;nach links
jsr links
jmp @+
#end
#if .byte stick0=#14 ;nach oben
jsr oben
jmp @+
#end
#if .byte stick0=#13 ;nach unten
jsr unten
jmp @+
#end
#if .byte stick0=#5 ;nach rechts unten
jsr rechts
jsr unten
jmp @+
#end
#if .byte stick0=#9 ;nach links unten
jsr links
jsr unten
jmp @+
#end
@
rts
.endp
Danke für die vielen tollen Tipps! Ich glaube ich sollte mehr Zeit mit lesen verbringen und experimentieren. Ich habe nun eine Joystick-Routine programmiert die mein Schiff nach links/und rechts bewegen soll:
;----------------------------------------------------------------------
; Move ship using Joystick 0
;----------------------------------------------------------------------
.proc moveShip
ldx #0 ; use joystick 0
lda STICK0,x
tay
and #%00000100
bne notLeft
lda shipPosX
cmp #$30 ; leftmost spritepos (48)
beq done
clc
sbc #1
sta shipPosX
sta HPOSP0
jmp done
notLeft
tya
and #%00001000
bne done
lda shipPosX
cmp #$c8 ; Rightmost spirtepos (200)
beq done
clc
adc #1
sta shipPosX
sta HPOSP0
done
rts
.endp moveShip
Die funktioniert grundsätzlich auch, jedoch ist das in Assembler alles so schnell das es faktisch nur links und rechts am Anschlag ist wenn man den Joystick kurz betätigt. Es muss also eine Art Bremse/Geschwindigkeit rein.
Überhaupt komme ich langsam an einen Punkt wo ich mir darüber Gedanken mache wie ich das Timing in einem Spiel steuern kann? Da sollen sich ja parallel mit unterschiedlicher Geschwindigkeit Dinge auf dem Bildschirm bewegen. Delays die einfach nur CPU-Zeit fressen sind ohnehin immer verpönt, also muss man eine Art real-time Ebene bauen. Ich stelle mir so eine Crontab vor in der ich angeben kann welche Routinen in welchen Zeitabständen aufgerufen werden. Diese Abstände geben dann die Geschwindigkeitsverhältnisse untereinander vor.
... entweder in den VBI stecken oder nimm die kleine Bremse, die ich dir gepostet habe
Dr. Irata schrieb: ... entweder in den VBI stecken oder nimm die kleine Bremse, die ich dir gepostet habe
Dazu ein paar Fragen. RTCLOK+2 ist ja das niederwertigste Byte des Registers. Das wird bei jedem VSYNC um 1 erhöht, also alle 1/50 Sekunden bzw. 20ms. Du machst im Code
lda RTCLOK+2
@ cmp RTCLOK+2
beq @-
Du lädst den aktuellen Wert des Byte in den Akku und vergleichst dann den Akku wieder mit dem Wert. Ich nehme mal an das die CPU sehr viel schneller Code ausführt als sich der Wert in RTCLOK+2 ändert, also loopt das solange bis ein VSYNC kommt, richtig? Also entspricht dies einem Delay von 20ms. Und dann verstehe ich auch das eine Ausführung im VBI (Vertical-Blank-Interrupt) dasselbe bewirkt.
genau
Prima, die X-Bewegung läuft nun mit Joystick und auch recht geschmeidig mit den 20ms Delay. Ach, hat jemand eigentlich eine Erklärung dafür das der Scroll nach links fast doppelt so schnell läuft wie der Scroll nach rechts?
yMoreT8 schrieb: Ich nehme mal an das die CPU sehr viel schneller Code ausführt als sich der Wert in RTCLOK+2 ändert, also loopt das solange bis ein VSYNC kommt, richtig? Also entspricht dies einem Delay von 20ms.
Mit dieser Methode verbrennst du halt extrem viel CPU Zeit, die du evtl. an anderer Stelle brauchen könntest.
Und dann verstehe ich auch das eine Ausführung im VBI (Vertical-Blank-Interrupt) dasselbe bewirkt.
Das ist aus obigem Grund die elegantere Lösung - so lange du im VBI genug Zyklen dafür übrig hast.
Alternative 1: Im VBI nur die neue Position berechnen und sie in einer Speicherstelle ablegen. Dein Hauptprogramm liest dann nur noch bei jedem Schleifen- bzw. Dispatcherdurchlauf diese Stelle aus und positioniert das Objekt entsprechend. Das kann ohne "Bremse" auch ein paar tausend Mal nacheinander passieren, ändert aber nichts weil bis zum nächsten VBI immer dieselbe Position angesteuert wird.
Alternative 2: Im Hauptprogramm nicht die Zeit verbrennen, sondern einfach immer nur dann etwas tun, wenn es sinnvoll ist. Das kann dann ggf. auch nur jeden zweiten oder hundersten VBI aktiviert werden.
lda RTCLOK+2
cmp saveRTCLOK
beq NixZuTun
sta saveRTCLOK
; den Joystick abfragen oder was auch immer
NixZuTun
ganz genau weiß ich es nicht, auf jeden Fal musst du vor der Subtraktion (sbc) statt clc sec nehmen!
So sollte es gehen - etwas kürzer und schneller - auch wenn schneller jetzt hier nicht nötig ist, aber wenn man später viel machen möchte ist jedes Häppchen wichtig.
;----------------------------------------------------------------------
; Move ship using Joystick 0
;----------------------------------------------------------------------
.proc moveShip
lda STICK0
tax
and #%00000100
bne notLeft
ldy shipPosX
cpy #$30 ; leftmost spritepos (48)
beq done
dey
sty shipPosX
sty HPOSP0
rts
notLeft
txa
and #%00001000
bne done
ldy shipPosX
cpy #$c8 ; Rightmost spirtepos (200)
beq done
iny
sty shipPosX
sty HPOSP0
done
rts
.endp moveShip
PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo
Dr. Irata schrieb: ganz genau weiß ich es nicht, auf jeden Fal musst du vor der Subtraktion (sbc) statt clc sec nehmen!
AAARGH 🤐 , ja, Du hast Recht, das war der Fehler! Danke!
Jetzt habe ich die Move-Routine in eine VBI gebaut. Den VBI löse ich in der DLIST im letzten JMP mit aus:
dl_ant4 = 4 ; ANTIC mode 4 (TEXT, 40x24)
dl_blank = %01110000 ; 8 blank lines in background-color
dl_jmp = %00000001 ; JMP
dl_vbi = %01000000 ; VBI
dl_lms = %01000000 ;
dlist .byte dl_blank, dl_blank, dl_blank ; 24 blank scanlines on top
.byte dl_lms | dl_ant4, <screen, >screen
:23 .byte dl_ant4
.byte dl_jmp | dl_vbi, <dlist, >dlist
Den Vektor dazu programmiere ich im INIT meines Spiels als immediate (ich mache ja kein kritisches IO):
lda #6 ;6=immediate, 7=deferred VBI
ldx #>VBROUT
ldy #<VBROUT
jsr SETVBV
Die VBROUT (den Namen habe ich einfach mal aus dem Atari-Buch übernommen) sieht dann so aus:
.proc VBROUT
jsr moveShip
jmp SYSVBV
.endp VBROUT
Die "moveShip" Subroutine macht dann die Joystickabfrage und Schiffsbewegungen, wenn nötig. Da der VBI ja nur alle 20ms beim VBLANK aufgerufen wird ist die Bewegung automatisch langsamer und zwar ohne CPU Zeit zu verbrennen. Wenn ich die Bewegung des Schiffes nicht mit ADC #1/SBC #1 mache sondern #2 oder #3, variiere ich die Geschwindigkeit. Das könnte später nochmal interessant werden um dem Spiel mehr Dynamik zu verleihen. Auch cool wäre eine Animation dabei (Schiff dreht sich leicht in die Bewegungsrichtung und zurück), sowie ein langsames anfahren und absenken der Bewegungsgeschwindigkeit. Das übersteigt aber gerade noch meine Möglichkeiten, führt mich aber wieder zu meinem o.g. Problem des Schedulers/Dispatchers und vermutlich Fließkomma-Arithmetik um sowas ordentlich zu berechnen, bzw. Daten-Tabellen in denen das vorberechnet wird. Aber das mache ich dann mal später...
Ich frage mich nur ob ich im INT-Handler nicht besser die NMIs ab und später wieder anschalten sollte? Bin mir noch nicht ganz sicher über die vielen Arten einen INT auszulösen und einen Handler dazu zu schreiben. Man müsste den VBI-Code, der sicher im laufe der Zeit wachsen wird, profilen um sicher zu stellen das dieser unter den maximal möglichen 4500 CPU-Taktzyklen bleibt die als Zeit zur Verfügung stehen?
Den Grundaufbau im Spiel sehe ich inzwischen in diese Blöcke unterteilt: 1.) Initialisierung und Defaults 2.) Main-Loop (Menüs/Highscore) 3.) VBI: Grafik aufbauen und bewegen. Kollisionserkennung, Spiellogik 4.) DLI: ? Weiss noch nicht was ich da machen soll/kann, vermutlich Farben ändern? Oder Scrolling?
Achja, Musik und Soundeffekte muss ich ja auch noch irgendwo mit einbauen.
Guten Morgen... viele Fragen, die Antworten werden sich erst mit der Zeit erschließen. Hier im Forum gibt es ein paar richtig erfahrene Hasen, die für sich genau den richtigen Weg gefunden haben, wie man was macht beim A8 - jeder scheint da aber einen etwas anderen Stil zu entwickeln. Grundsätzlich kann man ganz viel machen bei der kleinen Kiste - hätte ich übrigens am Anfang gar nicht so gedacht. Es gibt Limitationen, einige kann man etwas aushebeln, andere nicht.
Thema VBI: Ich habe am Anfang sehr viel Code in den VBI gepackt, dummerweise macht das dann irgendwann Probleme, wenn man ein Spiel für NTSC und PAL laufen lassen will. Mittlerweile versuche ich den Code dort möglichst schlank zu halten. Den VBI rufe ich am Anfang in der Initialisierungsphase auf und habe dann entsprechend eine eigene Proc für den VBI. Thema DLI: Wo fängt man an??? Wenn du mit DLI´s arbeitest, musst du dir vorher genau überlegen, was du damit machen möchtest und wie du entsprechend die DL aufbaust. Ja, man kann dort sehr schön die Farben der einzelnen Zeilen ändern, man kann damit auch Multicolorsprites machen, ich steuer die Hintergrundmusik mit einem DLI... usw..
Thema CPU: Am Ende ist es fast egal wie und wo du was machst, die CPU hat eine begrenzte Kapazität / Rechenpower. Wenn weg dann weg. Ob du das im VBI verbrätst oder im Hauptprogramm ist fast egal. Die Befehle zB im VBI müssen abgearbeitet werden und das kostet Rechenpower. Im VBI macht man eigentlich immer die Aktionen, die kritisch für den Bildaufbau sind / Thema Vermeidung von flackern - oder so Sachen, die ständig kontinuierlich abgefragt werden müssen (Joystick) oder wo die Bewegung glatt laufen muss (Player).
Wozu brauchst du Fließkomma???
So, ich habe die Joystick-Routine noch etwas angepasst, sodass man auch kombinierte Movements erkennt, also Links-Hoch, Rechts-Runter usw. Dann habe ich ein vertikales Scrolling in Form eines Byte-Roll im PM-Player RAM gebaut, sodass ich mein Schiff auch vertikal bewegen kann. Hier müssten wir nochmal gemeinsam schauen ob ich das so richtig mache oder ob es dazu HW-Methoden gibt dies das vertikale Scrolling vereinfachen?
Am Ende habe ich nun mal ein Video erstellt als Demo wo ich derzeit stehe. Als "Sterne" habe ich einfach im ANTIC 4 den Bildschirm voll mit "." ASCII-Zeichen gemacht, das dient nur der Simulation. Im Video zeige ich wie ich mein Schiff schön smooth in alle Richtungen, auch vertikal bewegen kann.
Das mag für die Profis hier nur gäähn/laaangweilig erscheinen, aber für mich persönlich ist das schon ein riesiger Meilenstein 🙂
leider kann ich mit Mac keine AVI abspielen
hier mal ein kleines Beispiel meiner Schiffsanimation meines aktuelle Projektes... 😉
Also du legst ja wirklich ein beeindruckendes Tempo in deiner Lernkurve vor. Hut ab.
Wenn du so weiter machst könnte da schon ein neuer Beitrag für den nächsten ABBUC Software Wettbewerb entstehen.
Weiter so !
... das sehe ich genauso!! Noch ist genügend Zeit, allerdings ist Galaxian schon eine echte Herausvorderung!!
Danke, aber Eure Mithilfe hat auch einen nicht unerheblichen Anteil daran! 🙂
Ich habe ja so kein richtiges Konzept, ist eher so on-the-fly. Vielleicht wird es garnicht ein Galaxian-Clone, sondern was eigenes... Aber ich habe Ideen und mal schauen was draus wird.
Ich würde mich auch furchtbar gern um das Thema Sound-Effekte und Musik kümmern, aber dafür bleibt grad gar keine Zeit. Wie ihr mach ich das ja alles in meiner Freizeit als Hobby und die Zeit ist eh schon knapp und es ist auch nicht mein einziges Hobby. Neben Elektronik, KFZ-Technik, Reverse-Engineering, ein paar Wikis und Foren sowie einem Dutzend weiterer Themenfelder nun auch noch Spiele-Entwicklung... 😉
Noch ein kleiner Tip:
Blättere doch auf jeden Fall mal dieses Forum durch (Softare/Programmierung)- Hier hat sich über die letzten Jahre einiges an Wissen angesammelt.
Hier mein kleiner Beitrag z.B. zum Thema VBI: https://abbuc.de/forum/viewtopic.php?f=7&t=928 Noch spannender ist aber noch das Timing des DLI, da muss man unter umständen dann wirklich jeden einzelnen Takt zählen 😉
. Hallo Peter
Dr. Irata schrieb: leider kann ich mit Mac keine AVI abspielen
Hast Du VLC probiert? Laut deren Website müsste VLC AVI abspielen können. Bin auf der Arbeit, hier gibt's nur Windoof, kann also nicht ausprobieren ob's stimmt.
Tschüß
Mathy
Schreibe nicht der Absicht zu, was man mit Dummheit oder Ignoranz erklären kann.
Dr. Irata schrieb: leider kann ich mit Mac keine AVI abspielen
Oh, sorry, hier nochmal als MP4 (.mov). Beim Abspielen hat er das aus irgendeinem Grund um 90° nach rechts gedreht, musst mal schaun ob das bei Dir auch so ist und ggf. korrigieren.
Mathy schrieb: . Hallo Peter
Dr. Irata schrieb: leider kann ich mit Mac keine AVI abspielen
Hast Du VLC probiert? Laut deren Website müsste VLC AVI abspielen können. Bin auf der Arbeit, hier gibt's nur Windoof, kann also nicht ausprobieren ob's stimmt.
Tschüß
Mathy
VLC kann (fast) alles 😎 ! (Auch AVI 😉)
Gtx. andY
Ressortleiter Hardware - Save the past and use the future!© andYManOne / Demozoo / Brandnew: Live 24/7 Stream - Industrial - Chiptune/Covers - Vocal Dream - EDM - Indie - own tracks
ja, ist gedreht bei mir... aber egal!
Für die Erstellung von Sprites oder Charaktern gibt es etliche Hilfsprogramme - die wirst gut brauchen. Ich nutze den Online SSpred von MatoSimi oder den SprEd aud gleicher Schmiede...
Dr. Irata schrieb: Für die Erstellung von Sprites oder Charaktern gibt es etliche Hilfsprogramme - die wirst gut brauchen. Ich nutze den Online SSpred von MatoSimi oder den SprEd aud gleicher Schmiede...
Genau, so eine Aufstellung von Tools wäre auch hilfreich. Ich hatte beim schnellen suchen diesen hier gefunden: SprEd v.1.2.1 https://bocianu.gitlab.io/spred/ der aussieht wie eine Weiterentwicklung des von Dir genannten SwSprEd v.0.8.4 https://bocianu.gitlab.io/spred/
Dann habe ich von ihm noch den Atari Fontmaker geladen: https://github.com/matosimi/atari-fontmaker#readme
So ganz blicke ich noch nicht durch, vor allem wie man mit den Farben umgeht und wie man später die Sprites zeichnet und animiert. Ich würde da unterscheiden in Verikales Scrolling und Animation bei Bewegung oder Zerstörung.
Man hat ja 4 Sprites (players) mit jeweils 128 oder 256 Byte Höhe. Diesen Block muss man ja erstmal im RAM per PMBASE zuweisen und initialisieren (mit 00en befüllen). Dann muss ich meine Spritedaten da rein kopieren und bestimmte mit der Startadresse auch die Y-Position. Wenn ich das Sprite dann bewegen will mache ich das horizontal über das HPOS Register und vertikal über Scrolling oder Bytemove. Hier sehe ich zwei Möglichkeiten: a) Ein echtes vertikal Scrolling verwenden b) Die Bytes im Sprite verschieben, also von unten nach oben oder umgekehrt einen Byteshift durch den player-data Bereich machen. c) Den gesamten 256 Byte Block des Players mit $00 löschen und das Sprite an der gewünschten Position neu einkopieren. d) Die Daten des Sprites an der letzten bekannten Position durch überschreiben mit $00 löschen und an der neuen gewünschten Position wieder einkopieren
Gibt es hier bevorzugte Methoden, bzw. habe ich eine übersehen? Ich persönlich würde Methode c) oder d) wählen weil es mir am flexibelsten erscheint. Ich kann so im Gegensatz zum zeilenweisen Scrolling direkt eine neue Position erreichen die mehrere Pixel von der alten entfernt ist. Aber das würde u.U. bedeuten das ich mein Sprite an einer Kollision vorbei bewegen könnte. Knifflig.
Bezüglich Animation wird man wohl eine Datenstruktur anlegen (Array) und irgendwo einen Index hinterlegen der beim zeichnen dann verschiedene Varianten des Sprites darstellt. Das zu steuern ist auch nicht ohne, da käme wieder sowas wie ein Scheduler zum Einsatz. Man kann sich ja auch in Ruheposition "wabernde" Gegner vorstellen, ebenso wie Animationen nur während einer Bewegung.
Und ist es so das man die Hintergründe (was so oft als Fields bezeichnet wird) dann über den ANTIC-Textmode und spezielle Fonts macht? Ggf. auch Gegner? Man hat ja nur 4 Sprites, das ist nicht viel und im Fall von Galaxian kann man die obere Reihe wohl eher nicht mit Sprites darstellen?
Auch ist mir noch ein Rätsel wie ich das mit dem animierten Sternenhintergrund hinbekomme. Hier wurde ja schonmal auf Missile diagnostiziert, aber mir fehlt noch jegliche Idee dazu das umzusetzen. Auch benötige ich die Missiles ja eigentlich für mein eigenes und das gegnerische Feuer?
Wie mal Fragen über Fragen... währenddessen ziehe ich mir die WUDSN Tutorials rein, lese div. Handbücher wie das Profi-Buch Seite für Seite durch und versuche aus zahlreichen Online-Quellen wie playermissile.com, AtariWiki etc. schlauer zu werden und ganz nebenbei noch das doch recht aufwändige 6502 Assembler zu lernen. Die fehlenden 16-Bit Register/Funktionen machen das Coding doch recht aufwändig, besonders bei Datenstrukturen die man ja nicht immer auf Page-Boundaries legen kann.
Also ich mache das aktuell so:
Mein Schiff besteht aus 2 Playern, dadurch erhalte ich drei Farben und es ist etwas breiter. Man kann theoretisch auch durch DLI´s aus einem Player einen mehrfarbigen Player machen, aber das ist etwas komplizierter und das brauche ich nicht zur Zeit. Mit dem SpriteEd habe ich dann den Sprite gezeichnet. Dieser Editor hat schon eine Abspielfunktion drin und hat auch schon die Funktion mit drei Farben drin. Die Daten kann man dann ganz einfach per copy/paste in das Programm übernehmen. Hier habe ich eine Extradatei in .txt Form angelegt, die Daten des Player lege ich dort per .dta ab. Die Datendatei wird mit icl eingebunden. Ein Unterprogramm welches ständig aufgerufen wird im VBI schreibt ständig die Werte aus der "Datenbank" in die jeweilige gewünschte ypos des Player ein. Ich habe immer über und unter den Playerdaten eine 0 - also Leerwert, das löscht immer den oberen und unteren Anteil des Player, alles andere wird jeweils vom neuen Wert überschrieben. Mit einem Zähler bestimme ich, welche Phase aus der "Datenbank" gelesen wird und in den Player eingeschrieben wird. Thats it...
übrigens besteht mein Schiff aus 2 Playern und 2 Missiles... aber das ändert ja nix von der Theorie her...
Hier mal mein Code - wie gesagt ich schreibe gerne mit IF Then weil es sehr übersichtlich ist, wenn es hart auf Zeit geht, wandel ich das später durchaus um:
; Endteil des Codes aus meinem VBI
lda xposp1
sta hposp0
sta hposp1
mva xposm1 hposm0
mva xposm2 hposm1
inc playerphasez
#if .byte playerphasez<#11
jsr playerphase1
#end
#if .byte playerphasez>#10 .and .byte playerphasez<#21
jsr playerphase2
#end
#if .byte playerphasez>#20 .and .byte playerphasez<#31
jsr playerphase3
#end
#if .byte playerphasez>#30 .and .byte playerphasez<#41
jsr playerphase4
#end
#if .byte playerphasez>#40 .and .byte playerphasez<#51
jsr playerphase5
#end
#if .byte playerphasez>#50 .and .byte playerphasez<#61
jsr playerphase6
#end
#if .byte playerphasez>#60
mva #0 playerphasez
#end
jsr joystick
inc explosionindex
plr
jmp xitvbv
und hier ein Ausschnitt der Daten meines Players (nur 1 Player - da fehlt dann noch der andere Player und die beiden Missiles... soll aber nur das Prinzip verdeutlichen:
; SPRITE COLORS 0
;dta 132, 132, 132, 132, 132, 132
; SPRITE COLORS 1
;dta 136, 136, 136, 136, 136, 136
sprite01 ; Frame 0
dta 0,0, 4, 0, 4, 0, 4, 27, 10, 4, 85, 21, 68, 32, 32, 0, 0,0
sprite02 ; Frame 1
dta 0,0, 0, 4, 0, 4, 4, 10, 10, 36, 4, 36, 27, 4, 0, 0, 0,0
sprite03 ; Frame 2
dta 0,0, 4, 4, 0, 4, 0, 16, 0, 20, 4, 21, 4, 0, 4, 0, 0,0
sprite04 ; Frame 3
dta 0,0, 4, 0, 4, 0, 4, 8, 8, 12, 4, 14, 0, 4, 0, 4, 0,0
sprite05 ; Frame 4
dta 0,0, 0, 4, 4, 0, 4, 1, 0, 5, 4, 21, 0, 0, 4, 0, 0,0
sprite06 ; Frame 5
dta 0,0, 4, 4, 0, 4, 4, 10, 10, 4, 4, 36, 27, 0, 0, 4, 0,0
Das macht wahrscheinlich jeder anders und wahrscheinlich bin ich der Einzige, der IF Then verwendet ;-)
yMoreT8 schrieb: b) Die Bytes im Sprite verschieben, also von unten nach oben oder umgekehrt einen Byteshift durch den player-data Bereich machen. c) Den gesamten 256 Byte Block des Players mit $00 löschen und das Sprite an der gewünschten Position neu einkopieren. d) Die Daten des Sprites an der letzten bekannten Position durch überschreiben mit $00 löschen und an der neuen gewünschten Position wieder einkopieren
Gibt es hier bevorzugte Methoden, bzw. habe ich eine übersehen?
Abgesehen von Methode a) haben tatsächlich alle so ihre Vor- und Nachteile. Wenn man den Player nur in einem sehr begrenzten Rahmen bewegt (also wie z.B. bei Crownland) dann würde ich Methode b) nutzen. Methode c) ist einfach, benötigt mehr CPU-Last aber weniger Verwaltungsaufwand. Methode d) benötigt weniger CPU-Last, dafür aber mehr Verwaltungsaufwand.
Finde Dein Engagement jedenfalls sehr gut.
Genau genommen benötigt es für Spieleentwicklung ja immer ein Grundgerüst, von dem Du Dir schon viel erarbeitet hast.
Displaylist Scrolling Interrupts (VBI und DLI) Timer P/M-Grafik Pokey-Programmierung
Dafür war ja mal eine Idee mit dem Wiki gedacht, aber leider komme ich nicht dazu, das bereits von Carsten eingerichtete Wiki auch mal zu füllen.
Ich nutze folgende Tools: Entwicklungsumgebung: wudsn mit mads als Assembler und Altirra als Emu und zum Souce-Level-Debugging Sprites: bocianus von Dir erwähnten SpriteEd Fonts: matosimis von Dir ebenfalls erwähnten FontMaker Sound/Chipmusik: RasterMusicTracker (RMT) von Raster (R.I.P.) http://raster.infos.cz/atari/rmt/rmt.htm#download bzw. in einer überarbeiteten aber strubbeligen Fassung von VinsCool https://github.com/VinsCool/RASTER-Music-Tracker
Ich habe mir das Image von "Galaxian (1982)(Atari)(US)[a].exe" im Altirra Debugger näher angeschaut um zu lernen. Der Code wird laut COM Prefix ab $5500 geladen. Das DLIST Register wird auf $3D00 gesetzt und die dort liegende DLIST kann man mit einem Kommando in der Altirra Console prima debuggen:
Altirra> .dumpdlist $3d00
3D00: blank.i 8
3D01: blank 8
3D02: mode.i 6 @ 0B20
3D05: blank 6
3D06: mode.v.h E @ 1028
3D09: x7 mode.v.h E
3D10: mode.i.v.h E
3D11: blank 4
3D12: x8 mode.v.h E
3D1A: mode.i.v.h E
3D1B: blank 4
3D1C: x8 mode.v.h E
3D24: mode.i.v.h E
3D25: blank 4
3D26: x8 mode.v.h E
3D2E: mode.i.v.h E
3D2F: blank 4
3D30: x9 mode.v.h E
3D39: blank 4
3D3A: blank 3
3D3B: x5 blank 8
3D40: mode 6 @ 1E00
3D43: blank 8
3D44: blank.i 8
3D45: x2 blank 8
3D47: blank 1
3D48: x7 blank 8
3D4F: mode.h E @ 0818
3D52: x8 mode.h E
3D5A: mode.i.h E
3D5B: blank 1
3D5C: mode 2 @ 2D00
3D5F: waitvbl 3D00
Es ist also ein durchaus komplexer Mix verschiedener Graphics-Modes, teilweise mit LMS zu eigenen RAM-Locations und Blanks.
Ich nutze folgende Tools: Entwicklungsumgebung: wudsn mit mads als Assembler und Altirra als Emu und zum Souce-Level-Debugging Sprites: bocianus von Dir erwähnten SpriteEd Fonts: matosimis von Dir ebenfalls erwähnten FontMaker Sound/Chipmusik: RasterMusicTracker (RMT) von Raster (R.I.P.) http://raster.infos.cz/atari/rmt/rmt.htm#download bzw. in einer überarbeiteten aber strubbeligen Fassung von VinsCool https://github.com/VinsCool/RASTER-Music-Tracker
Um mal das komplette Gegenteil zu zeigen:
Ich nutze folgende Tools: Entwicklungsumgebung: IntelliJ-CE und Emacs als Editor, Makefiles um die Abhängigkeiten aufzulösen, atasm v1.23 und atari800 oder Altirra, falls ich debuggen muss. Des Weiteren verwende ich meist meine selbst geschriebene Algol 68 ähnliche Sprache zum Programmieren von Dingen, die nicht soo zeitkritisch sind. Sonst natürlich Assembler. Der Compiler nimmt mir echt eine Menge Dinge ab. Das ist dann wie programmieren mit Action oder Basic nur halt ähnlich schnell wie Assembler. Als Tipp: Ich lege meine Sprite/Font-Daten meist als Binärzahlen im Sourcecode ab, dann sind die Dateien zwar locker 8x größer, aber auf einem aktuellen PC spielt das keine Rolle. So könnte ich auch schnell Dinge anpassen im Sourcecode. Statt Oktal unterstützt mein Compiler die Quad-Zahlen (0-3) damit lassen sich dann mehrfarbige Fonts einfach anlegen. Grundsätzlich verwende ich Git als Revision-Controll-System. Bei mir lokal auf meinem Server rennt ein Gitea, das verwende ich ausgiebig. Als Sprite-Editor nehme ich gerne Piskel, damit kann man sehr schnell Animationen zaubern. Für Sounds habe ich mir selbst etwas zusammengezimmert, nicht weil ich RMT nicht mag, sondern weil ich es einfach wollte.
Hi Y - was macht deine Programmiereuphorie? Kommst du voran?